home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / src / swtools / DSOs / compiler-DSOtricks next >
Encoding:
Text File  |  1994-08-02  |  6.9 KB  |  195 lines
  1.  
  2.            ~4Dgifts/toolbox/src/swtools/DSOs compiler-DSOtricks 
  3.  
  4.  
  5.  
  6.         Compiler / DSO tricks
  7.  
  8.     1) DSO's
  9.  
  10.        A dynamic share object (DSO) is an object file that's 
  11.        meant to be used simultaneously - or shared - by multiple 
  12.        applications (a.out files) while they're executing.  You 
  13.        can use DSOs in place of archive libraries.  By using DSOs, 
  14.        you minimize memory use because code is shared.  Also, you 
  15.        minimize disk use.  Executables linked with DSOs are smaller 
  16.        than those linked with unshared libraries because the shared 
  17.        objects aren't part of the executable file image.
  18.  
  19.         - setenv _RLD_ARGS -v
  20.             It will print each DSO routine by name the
  21.             first time it is called.  
  22.  
  23.          -dlopen("libil.so",RTLD_LAZY)
  24.  
  25.          -sgidladd()
  26.             this permits one to dynamically add a library as if
  27.             it has been on the link line - it does NOT require
  28.             one to change code to call indirectly through
  29.             pointers
  30.  
  31.     2) QuickStart & Conflicts
  32.  
  33.         There seems to be a confusions between quickstart and
  34.         conflicts.  The fact that an object has conflicts does not
  35.         mean that it can not quickstart, although if there are
  36.         conflicts rld will have to do more work than if there are
  37.         not.  Quickstart fails primarily because the app and the
  38.         objects it will load are out of sync.  A typical example is
  39.         you are building an app that links against a dso, libA.so,
  40.         which in turn links against libc.so.1.  Now if the
  41.         libc.so.1 on your machine does not match the libc.so that
  42.         was used when building libA.so, your app will be marked as
  43.         non-quickstart by ld.  The same holds true when rld runs.
  44.  
  45.         Conflicts deal with overriding behavior in objects that
  46.         will be loaded.  For example lets assume that your
  47.         application links against libmalloc.so and libc.so.1.  Thus
  48.         it should use the malloc from libmall not libc.  However
  49.         there are calls in libc.so.1 to malloc and those have been
  50.         resolved internally to the libc's malloc.  Now when running
  51.         the application those references have to be changed to
  52.         point to the malloc routines in libmalloc.  That is what
  53.         the conflict list is used for.
  54.  
  55.     3) Lint 
  56.  
  57.         Check out "Writing Solid Code" -- the book which Tom Davis said
  58.         "would change the way he programmed" devotes the first chapter
  59.         to tactics which prevent bugs at compile time.  It seems like a
  60.         no-brainer to use -wlint and compile -xansi (the default).
  61.  
  62.  
  63.  
  64.     4) Improving Program Performance (IRIX System Programming Guide Ch3)
  65.  
  66.         Improving Global Optimization
  67.  
  68.         This section contains coding hints recommended to increase
  69.         optimizing opportunities for the global optimizer (uopt).
  70.         Apply these recommendations to your code whenever
  71.         possible.
  72.  
  73.         C and Fortran Programs
  74.  
  75.         The following suggestion applies to both C and Fortran
  76.         programs:
  77.  
  78.         Do not use indirect calls. Avoid indirect calls (calls that
  79.         use routines or pointers to functions as arguments).
  80.         Indirect calls cause unknown side effects (that is, they
  81.         change global variables) that can reduce the amount of
  82.         optimization possible.
  83.  
  84.         C Programs Only
  85.  
  86.         The following suggestions apply to C programs only:
  87.  
  88.         Return values. Use functions which return values instead of
  89.         pointer parameters.
  90.  
  91.         Do while. Use do while instead of while or for when
  92.         possible. For do while, the optimizer does not have to
  93.         duplicate the loop condition in order to move code from
  94.         within the loop to outside the loop.
  95.  
  96.         Unions. Avoid unions that cause overlap between integer and
  97.         floating point data types. The optimizer will not assign
  98.         such fields to registers.
  99.  
  100.         Use local variables. Avoid global variables. In C programs,
  101.         declare any variable outside of a function as static,
  102.         unless that variable is referenced by another source file.
  103.         Minimizing the use of global variables increases
  104.         optimization opportunities for the compiler.
  105.  
  106.         Value parameters. Pass parameters by value instead of
  107.         passing by reference (pointers) or using global variables.
  108.         Reference parameters have the same degrading effects as the
  109.         use of pointers (see below).
  110.  
  111.         Pointers and aliasing. You can often avoid aliases by
  112.         introducing local variables to store the values obtained
  113.         from dereferenced pointers. Indirect operations and calls
  114.         affect dereferenced values, but do not affect local
  115.         variables.  Therefore, local variables can be kept in
  116.         registers. The following example shows how the proper
  117.         placement of pointers and the elimination of aliasing
  118.         produces better code.
  119.  
  120.     5) prof (IRIX System Programming Guide Ch3)
  121.  
  122.         Use the procedure below to obtain pc sampling information
  123.         (refer to Figure 3-1 ).
  124.  
  125.         1.Compile the program using the appropriate compiler
  126.         driver. For example, to compile a C program myprog.c:
  127.  
  128.         IRIS% cc -c myprog.c
  129.  
  130.         2.Link-edit the object file created in Step 1.
  131.  
  132.         IRIS% cc -p -o myprog myprog.o
  133.  
  134.         Note:  You must specify the p profiling option during this
  135.         step to obtain pc sampling information.
  136.  
  137.         3.Execute the profiled program. (During execution,
  138.         profiling data is saved in the file mon.out.)
  139.  
  140.         IRIS% myprog
  141.  
  142.         You can run the program several times, altering the input
  143.         data, to create multiple profile data files. Use the
  144.         environment variable PROFDIR as explained later in this
  145.         section.
  146.  
  147.         4.Run the profile formatting program prof.
  148.  
  149.         IRIS% prof myprog mon.out
  150.  
  151.         prof extracts information from mon.out and prints it in an
  152.         easily readable format. For more information see the
  153.         prof(1) manual page.
  154.  
  155.     6) pixie (IRIX System Programming Guide Ch3)
  156.  
  157.         Use the procedure below to obtain basic block counts (refer
  158.         to Figure 3-2 ).
  159.  
  160.         1.Compile and link edit your program normally. Do not use
  161.         the p option. For example, using the input file myprog.c:
  162.  
  163.         IRIS% cc -o myprog myprog.c
  164.  
  165.         The cc compiler compiles myprog.c into an executable called
  166.         myprog.
  167.  
  168.         2.Run pixie to generate the equivalent program containing
  169.         basic-block-counting code.
  170.  
  171.         IRIS% pixie myprog -o myprog.pixie
  172.  
  173.         pixie takes myprog and writes an equivalent program
  174.         containing additional code that counts the execution of
  175.         each basic block. pixie also generates a file called
  176.         myprog.Addrs which contains the address of each basic
  177.         block. For more information, refer to the pixie(1) manual
  178.         page.
  179.  
  180.         3.Execute the file generated by pixie, myprog.pixie, in the
  181.         same way you would execute the original program.
  182.  
  183.         IRIS% myprog.pixie
  184.  
  185.         This program generates a list of basic block counts in a
  186.         file named myprog.Counts.
  187.  
  188.         4.Run the profile formatting program prof specifying the
  189.         pixie option and the name of the original program.
  190.  
  191.         prof -pixie myprog myprog.Addrs myprog.Counts
  192.  
  193.         prof extracts information from myprog.Addrs and
  194.         myprog.Counts and prints it in an easily readable format.
  195.